The two sides of the authenticated scans (PCI DSS req. 11.3.1.2)

Another relevant change in PCI DSS version 4.0 was the evolution of internal vulnerability scans from a network-based approach (PCI DSS v3.2.1) to an authenticated approach, which allows full visibility into the internal configuration of the analyzed host. This new approach can be seen as a substantive improvement from a security point of view, but it opens the door to another problem: the management of the administrative credentials and permissions used by this type of scans. In this article we explain how to avoid surprises and implement this control in a safe way.

As explained in the article Analysis of PCI DSS v4.0 Part VI: Requirements 10 and 11, probably one of the most relevant changes in PCI DSS is the inclusion of the concept of “authenticated scans” (authenticated scanning). This approach allows internal scans to go beyond the detection of vulnerabilities from the network point of view and evolve towards the identification of vulnerabilities from the point of view of the asset (host), giving greater visibility to the results and incorporating not only the vulnerabilities of the services published in data networks but also of the local software and its configuration.

Differences between traditional vulnerability scanning and authenticated scanning

The requirement in question is 11.3.1.2, which reads:

The good side of authenticated scans

As I said Benjamin Disraeli, As a rule, the man who is most successful in life is the one who has the best information. From a security point of view, the more information you have about an asset, the definition of its controls can be refined in a more adjusted way. And this is the case with authenticated scans: provide more information to the entity about the status of a particular asset, including exposed ports and protocols, running services, users and groups, permissions, connected peripherals, updates, etc. allowing to know its security level at a particular time.

The Bad Face of Authenticated Scans

However, to achieve that level of visibility in an asset, generic permissions are not enough: administration privileges are required .

From a technical point of view, this can be achieved through two approaches:

• Through agents: The installation of an agent in the host to be analysed (local agent). This agent must be executed with administrative privileges so that it can properly evaluate the system without restrictions.
• No agents (agentless): In systems where you do not want or cannot install agents (either for incompatibility with supported operating systems, for the use of appliances, etc.), scans can be performed remotely without local agents installed. To do this, the scanner must have a remote method and connection (SSH, SNMP, WMI, API, shared resources, etc.) and have valid administration credentials (usernames and passwords or digital certificates) that must be provided to the scanner to be able to remotely authenticate and execute the necessary tests.

And this is precisely where the irony comes from, since the vulnerability scanning tool automatically becomes an attack vector:

• If the scanning tool console is compromised, the attacker will be able to control the agents and/or access the stored credentials.
• If installed local agents are compromised, the systems that have those agents will also be compromised (as they run with administration privileges).
• If the credentials used for agentless scans (which are supposed to have administrative privileges) are compromised, all systems where authentication can be done will be compromised.
• Because the scanner must have unrestricted access at the network level in order to analyze the target host, an attacker can use those privileges to access the networks of the systems to be scanned.

Recommendations

As indicated in the same requirement, these accounts must be managed through requirement 8.2.2:

These controls may be fine in certain circumstances, but depending on the scanning tool and the infrastructure to be analyzed, they may fall short, exposing the institution to potential risks.

Therefore, from PCI Hispano we recommend the implementation of the following additional controls:

• Stipulate specific time periods for the scans and monitor any actions performed with the accounts used in the authenticated scans outside those periods.
• For centralized accounts (e.g. active directory accounts or LDAPs):
  • Rotate frequently the passwords used.
  • Enable these accounts only when scan periods are active.
  • If possible, remove administrative privileges to the account when not in use.
• Depending on the operating system restrictions to be analyzed, employ privilege escalation controls (su, sudo, etc.)
• Restrict the interactive use of the account used for authenticated scans. For example, in Unix systems you can be assigned a shell non-interactive as /bin/nologin, /bin/false o /bin/true.
• Enable firewall rules at the perimeter or local level on the systems that support it to allow remote access from the scanner only during the time periods in which the scan is being done. Once finished, the rules must be disabled.
• Preferably use certificate-based authentication instead of passwords.
• If the organization has a privileged access management system (Privileged Access Management – PAM), then link the accounts used in the authenticated scans with that tool.

Finally, it is not recommended to run authenticated scans with accounts without administrative privileges or manually profiled privileges, as scan results may be erroneous, partial or have false positives.